Referring to FIG. 1, as is well known, computer systems attached to data networks 10 are often connected in a client-server fashion, with a single server 12 servicing requests from multiple clients 14. The number of clients 14 that can be serviced by a single server 12, and thus the cost-effectiveness of the system, is dependent on how efficiently each transaction can be processed.
There are two chief costs to be considered in the design of such a system. One is the computational efficiency of the transfer protocol itself, and the other is the effective utilization of the network 10 between the client 14 and the server 12.
The computational efficiency of the protocol is a measure of the amount of work to be performed by the endpoints, namely the client 14 and server 12, in order to reliably transfer a given amount of information. The focus of attention is on the work required by the server 12, since it is processing requests from a potentially very large number of clients 14. The less work that needs to be performed by the server 12, the lower the cost to the system for providing the service.
From the point of view of the server 12, there are two components to the computational cost of a data transfer protocol. The first is the cost of actually transferring the desired data, and the second is the protocol overhead, which includes every CPU cycle executed which is not directly involved with transmitting the data. This may include connection setup, acknowledgement processing, retransmission, and connection teardown. It also includes the cost of processing (e.g., interrupts and protocol stack overhead) each unique incoming and outgoing PDU (protocol data unit) and any associated header.
While there is a minimum cost of the data transfer itself that cannot be avoided, the protocol overhead associated with the transfer can be reduced.
An independent problem from computational efficiency is network efficiency, which is a measure of how much useful data is carried through the network 10 to the destination as compared to how much was offered to it. Data loss, typically caused by network congestion, is a factor in any network 10 with shared components, where it is possible for instantaneous network load to exceed capacity. In a reasonably engineered network 10, congestion is typically bursty, corresponding to burstiness in the offered data traffic.
There are several approaches to increasing protocol efficiency, particularly be decreasing the protocol overhead. One way to decrease protocol overhead is to increase the size of outgoing PDUs. This amortizes the per-PDU cost over a larger amount of data and requires fewer PDUs to complete the transfer, reducing the total cost of the transfer. Trivial File Transfer Protocol (TFTP), which is based on the well known User Datagram Protocol over the Internet Protocol or UDP/IP, is an example of a protocol that allows an increase in its PDU size to gain efficiency.
Another way to decrease protocol overhead is to reduce the number of incoming PDUs. For example, a TFTP file transfer requires one incoming acknowledgement PDU for each outgoing data PDU. This results in a high transfer cost to the server. In contrast, the TCP-based FTP uses a windowing scheme, where multiple outgoing PDUs may be acknowledged by a single incoming PDU.
Yet another way involves selective retransmission. Windowed protocols that use a go-back-n retransmission scheme can cause successfully received data to be discarded and retransmitted. By causing only the lost data to be retransmitted, unnecessary work at the server can be avoided. Protocols such as XTP implement selective retransmission.
Some transport mechanisms, such as a connectionless transport mechanism, are inherently simpler and more efficient than others. A connectionless, non-guaranteed service like UDP/IP, (as used by TFTP) may be considerably more efficient than reliable, connection-oriented TCP or ISO TP4 for data movement. However, since UDP does not provide the same traffic integrity guarantees as TCP, the responsibility for ensuring reliable transfer lies with the file transfer mechanism itself rather than the underlying system.
All else being equal, increasing either the PDU size or the acknowledgement window increases the chance of network congestion. More data is being sent in each burst to the network. Unless there is some sort of way to limit this traffic, network congestion will increase, leading to data loss and more retransmission, leading back to more work for the server. Unfortunately, most solutions which increase network efficiency tend to increase the computational cost of moving data.
Though designed as an end-to-end mechanism to prevent message loss due to buffer depletion, modified flow control mechanisms can be used to aid network stability. TCP takes an approach that dynamically varies the acknowledgement window based on end-to-end message loss. This can detect and recover from network congestion, but at the cost of considerable overhead on the part of the sender, and at the cost of needing to induce network congestion before it can be detected.
Another solution to network congestion is explicit peer-to-peer rate/flow control, as exemplified in the ATM ABR (available bit rate) scheme. In this scheme, the instantaneously available network bandwidth is advertised to the endpoints, which are expected to limit output accordingly. Unfortunately, this capability is not widely available and is computationally expensive both for the server and the network.